Workflows
A strategic benefit to using WF
is that it allows for the use of a common workflow technology to build
workflow solutions across other Microsoft products and .NET solution
environments.
WF supports both system workflows and human workflows by supporting two built-in workflow types:
sequential workflows
state machine workflows
Both rely on the same
runtime environment and the same set of standard WF activities. A single
workflow definition can also be a composite of both types, containing
activities that rely on the system and on human action. Let’s briefly
explore each workflow type a bit more.
Sequential Workflows
Sequential
workflows execute activities in a pre-defined pattern. This workflow
type is better suited for system workflows because the execution of
activities closely resembles a flowchart with branches, decision logic,
loops, and other control structures.
By using WF, rather than
embedding workflow routines into the core logic of individual services,
each step in the business process is defined explicitly in a graphic
designer and executed by the workflow engine. This corresponds directly
to Process Centralization together with additional patterns that co-exist to establish an environment as per the Orchestration compound pattern.
The resulting level of
separation can cleanly partition agnostic and non-agnostic logic
allowing for the definition of reusable services that are independently
maintainable. This is essentially the basis of Functional Decomposition , which is commonly further supplemented with the sequential application of Service Encapsulation, Agnostic Context , Non-Agnostic Context , and Agnostic Capability.
These foundational service patterns can be applied to form primitive
service modeling and design processes that are initiated with
well-defined workflow logic and carried out using WF tools, such as
Workflow Designer (explained shortly).
Applying these patterns generally leads to the need to further define the functional contexts of services via Service Layers, such as those established by the application of the Utility Abstraction , Entity Abstraction, and Process Abstraction .
Agnostic utility and entity services that result from the application
of the former two patterns need to be separated within or outside of WF
in order to avoid unnecessary performance overhead and synchronization
issues due to deployment-level dependencies on the orchestrated task
service logic that encapsulates parent workflow routines.
|
State Machine Workflows
State machine workflows
execute activities as external events occur. This type (based on the
well-known Finite State Machine) is better suited for workflows
involving human intervention. The subsequent activity to be executed
depends on the current state and the event it has received. State
machine workflows are useful when the sequence of events is not known in
advance or when the number of possibilities makes defining all possible
paths impractical.